1. Technical Field
The present invention relates to a packet transmission system, packet transmission method, data reception system, and data reception method adapted for real-time transmission.
2. Background Art
Transmissions on networks such as the Internet are characterized in that they are packet type transmissions and that they are best effort transmissions.
Packet type transmissions (hereinafter referred to as packet transmissions) are characterized in that transmissions are made in units of data structures called packets. Each communicated packet contains data portions produced by dividing source data such as voice and additive information such as destination information.
Furthermore, the best effort transmissions are characterized in that the quality of transmission is not guaranteed. This means that neither the delay time with which sent packets arrive at their destinations nor the order in which they arrive are assured. In addition, the arrival itself is not assured.
An examples of a method of assuring the arrival of packets to their destinations include TCP (Transmission Control Protocol) that is a connection-oriented transmission protocol stipulated in IETF standard RFC793.
In packet transmission using TCP, a receipt acknowledgment packet (hereinafter referred to as the ACK packet) responding to the arriving data is sent from the receiver unit to the sender unit. Consequently, the sender unit can confirm that packets sent from the unit itself have arrived at the receiver unit. The packets will be retransmitted unless ACK packets arrive from the receiver unit. This can assure arrival of the packets at the destination. This is briefly described with reference to FIGS. 10 to 14.
FIG. 10 schematically illustrates additive information added to data (data to be sent such as voice) contained in individual packets used in TCP. Of these packets, sequence number (hereinafter referred to as SEQ number), receipt acknowledgment number (hereinafter referred to as ACK number), and window size (hereinafter abbreviated WIN) are especially associated with the description of the present invention.
FIG. 11 schematically illustrates simplified packet transmission operations using TCP regarding IETF standard RFC793. In FIG. 11, a packet sent first from a sender unit is referred to as packet A. SEQ:2000 of this packet A indicates that the SEQ number is 2000 and denotes the data position of the data contained in the sent packet on the source data.
Generally, data position on source data can be indicated by “SEQ number value of packet-initial value of SEQ number”. For example, if the initial value of the SEQ number of the packet A is 0, the “SEQ:2000” of the packet A indicates that the data contained in the packet A is data items beginning with the 2000th byte from the head of the source data. The initial value of the SEQ is not limited to 0. In the following description, however, the initial value of the SEQ number is set to 0.
ACK:1000 of the packet A indicates that the ACK number is 1000. In this embodiment, that the ACK number is 1000 has no special meaning. In the following description, the position on the source data of data contained in each packet is referred to as the “position of the packet on the source data”.
It is also assumed that the lengths of data items contained in packets sent from a sender unit to a receiver unit are all 100 bytes.
When the packet A is received by the receiver unit, the unit creates an ACK packet a as a receipt acknowledgment. The ACK packet a is sent to the sender unit. ACK:2100 of the ACK packet a indicates that the ACK number of the ACK packet a is 2100. In this case, the “2100” means that the SEQ number of the packet A is 2000 and that the length of the data contained in the packet A is 100. Hence, “2100” is their sum.
The “ACK:2100” means that the receiver unit requests the sender unit to perform transmission of a next data set beginning at data position of 2100, it being noted that the head position of the source data is set to 0. Alternatively, it means that the receiver unit has now received a data set that is the 2100 bytes from the head of the source data.
In the ACK packet a, any data to be sent from the receiver unit to the sender unit does not exist. Therefore, the ACK number “1000” described in the packet A is used intact as the SEQ number of the ACK packet a and described as “SEQ:1000”. Similarly, the receiver unit creates an ACK packet h in response to a packet B sent from the sender unit.
It is now assumed that a packet C has suffered from a loss for some cause as shown in FIG. 11. In a packet transmission utilizing TCP, the sender unit sets a timeout time defined to be the ACK packet arrival wait time as indicated by the bold arrow Ts in the figure during packet transmission. If no ACK packet from the receiver unit arrives within the timeout time, the sender unit determines that the packet (packet C in this example) has suffered from a loss. The packet C with packet loss is retransmitted as a packet D.
In FIG. 11, the sender unit waits for an ACK packet from the receiver unit for each one packet. In practice, for more efficient transmission, a packet transmission using a window control utilizing a setting of the window size is made.
FIG. 12 illustrates an example of packet transmission operation using TCP in a case where the window size has been set in a given manner regarding IETF standard RFC793. Also, in this example, it is assumed that data items contained in packets sent out from the sender unit are all 100 bytes. For simplicity, the window size is assumed to be 400 bytes corresponding to a data size corresponding to 4 packets.
Using this window control, the sender unit can perform continuous packet transmission without waiting for ACK packets from the receiver unit until the window size is reached.
In FIG. 12, three packets are sent without waiting for ACK packets (in this example of FIG. 12, packets with SEQ:2000, SEQ:2100, and SEQ:2200 are sent without waiting for ACK packets from the receiver unit). Subsequently, packets up to four can be sent without waiting for ACK packets. A comparison of FIGS. 11 and 12 reveals that the method of FIG. 12 permits a more efficient packet transmission.
FIG. 13 schematically illustrates processing performed where a packet loss has occurred in the method of FIG. 12. As shown in FIG. 13, packets A, B, C, and D up to four, in this case, can be transmitted without waiting for ACK packets.
It is assumed that the packet B of the sent packets suffered a loss. Then, the sender unit sends a packet E in response to arrival of the ACK packet a corresponding to the packet A at the sender unit. However, because of the packet loss in the packet B, an ACK packet corresponding to the packet B is not sent back. The packets C, D, and E are received by the receiver unit normally but transmission of ACK packets corresponding to the packets C, D, and E is withheld because of the packet loss in the packet B.
In the sender unit, a timeout time (packet arrival maximum wait time) indicated by the bold arrow Ts is set from the transmission of the packet B. Where any ACK packet does not arrive within the timeout time, it is judged that a timeout and a packet loss in the packet B have occurred. The same packet as the packet B is retransmitted as packet F.
In the receiver unit that has received the packet F, data carried by the packets C, D, and E are made effective by the reception of the packet F. Therefore, an ACK packet f including the data is sent back.
In contrast with this method, a method stipulated in IETF standard RFC2582 is available. FIG. 14 illustrates one example of packet transmission operation using TCP regarding IETF standard RFC2582. This method monitors packet loss using an ACK packet from the receiver unit instead of using a timeout time as in the aforementioned method of FIG. 13.
In FIG. 14, it is also assumed that a packet loss has occurred in the packet B in the same way as in FIG. 13. It is assumed that the receiver unit has received the packet C after the ACK packet a responsive to the packet A is sent. Thus, the receiver unit detects that at least one packet has suffered from a packet loss. At this time, the receiver unit sends ACK packets a′ and a″ which are identical in content with the ACK packet a.
The same ACK packet was sent plural times from the receiver unit. The ACK number of the corresponding packet, i.e., ACK packet a, is 2100 (ACK:2100). Therefore, the sender unit can know that a packet loss has occurred in the packet B having a SEQ number of 2100 (SEQ:2100). Therefore, the packet B with packet loss is retransmitted as the packet F.
As can be appreciated from a comparison of FIGS. 13 and 14, the method of FIG. 14 can resume the data transmission more quickly than the method of FIG. 13.
The description provided thus far has assumed that any packet from the sender unit has a packet loss. Processing of similar contents is performed in a case where any ACK packet from the receiver unit has a packet loss.
In this way, with respect to packet transmission using TCP, arrival of each packet at the destination is checked using an ACK packet from the receiver unit. With respect to a packet for which an ACK packet is not received and thus arrival is not confirmed, retransmission is performed. This ensures the integrity of the transmission.
However, where real-time data such as voice and moving pictures is communicated on the Internet, UDP (User Datagram Protocol) that is a connection-less communication protocol stipulated in IETF standard RFC768 is often used. In this UDP, no handshake is performed between the sender and receiver. When a packet loss has occurred, retransmission of a packet is not performed.
FIG. 15 schematically illustrates the additive information contained in each packet and used in UDP regarding IETF standard RFC768. In packet transmission using UDP, data corresponding to SEQ number, ACK number, and WIN are not contained unlike the additive information in a packet in the case of TCP (see FIG. 10), because packet transmission using UDP does not perform a handshake, unlike packet transmission using TCP. In packet transmission using only UDP, neither packet loss nor reversal of the orders of arrival can be detected.
FIG. 16 illustrates one example of packet transmission operation using UDP regarding IETF standard RFC768. As can be appreciated from FIG. 16, packets from a sender unit are transmitted at regular intervals of time irrespective of presence or absence of packet loss. This is adapted for real-time transmission such as voice and moving pictures. On the other hand, as mentioned previously, retransmission is not performed when there is a packet loss. Arrival of the packet at the destination is not assured. Furthermore, the orders of arrival are not assured.
When there is a packet loss during transmission using a simple TCP, the system waits for an ACK packet within the timeout time as already described in connection with FIGS. 11 and 13. Where no ACK packet arrives after the expiration of the timeout time, retransmission is performed. Therefore, transmission is suppressed, and there is a possibility that a large delay occurs.
Furthermore, in the packet transmission using the method described in connection with FIG. 14, a delay at least corresponding to transmission of plural ACK packets takes place, though the processing is made faster than the simple transmissions shown in FIGS. 11 and 13.
However, in real-time transmission in which transmission delay of packets poses problems, such retransmission processing cannot be used. That is, in real-time data such as voice and moving pictures, even if a packet resulting in a packet loss arrives because of retransmission, data contained in the retransmitted packet will be meaningless unless packets can keep up with the playback timing.
On the other hand, in packet transmission using UDP, delay in the sender unit due to suppression of transmission involving such retransmission does not take place. However, in transmission using UDP, there is the problem that passage of packets using UDP is frequently prohibited by firewalls, for the following reason. Voice and moving pictures communicated in real time have quite large amounts of data. If they are permitted to pass, the transmission speeds of other transmissions are likely to be deteriorated.
As described so far, the prior art technique has the problem that it is difficult to guarantee the real-timeness of packet transmission using TCP. In packet transmission using UDP, there is the problem that passage of data is prohibited by a firewall or the like.
Accordingly, it is an object of the present invention to provide packet transmission system, packet transmission method, data reception system, and data reception method capable of securing real-timeness in the same way as packet transmission using UDP although packet transmission using TCP is employed.